#How to Change Branch in Git

[johnusa4567]

How to Change Branch in Git – Simple Guide

Learn how to change branch in Git with step-by-step instructions at Vultr. Whether switching to an existing branch or creating a new one, this guide simplifies the process. Perfect for beginners and developers managing multiple branches. Visit Vultr for complete Git command insights.

[codingquill]

Welcome back, coding enthusiasts! Today we'll talk about Git & Github , the must-know duo for any modern developer. Whether you're just starting out or need a refresher, this guide will walk you through everything from setup to intermediate-level use. Let’s jump in!

What is Git?

Git is a version control system. It helps you as a developer:

Track changes in your codebase, so if anything breaks, you can go back to a previous version. (Trust me, this happens more often than you’d think!)

Collaborate with others : whether you're working on a team project or contributing to an open-source repo, Git helps manage multiple versions of a project.

In short, Git allows you to work smarter, not harder. Developers who aren't familiar with the basics of Git? Let’s just say they’re missing a key tool in their toolkit.

What is Github ?

GitHub is a web-based platform that uses Git for version control and collaboration. It provides an interface to manage your repositories, track bugs, request new features, and much more. Think of it as a place where your Git repositories live, and where real teamwork happens. You can collaborate, share your code, and contribute to other projects, all while keeping everything well-organized.

Git & Github : not the same thing !

Git is the tool you use to create repositories and manage code on your local machine while GitHub is the platform where you host those repositories and collaborate with others. You can also host Git repositories on other platforms like GitLab and BitBucket, but GitHub is the most popular.

Installing Git (Windows, Linux, and macOS Users)

You can go ahead and download Git for your platform from (git-scm.com)

Using Git

You can use Git either through the command line (Terminal) or through a GUI. However, as a developer, it’s highly recommended to learn the terminal approach. Why? Because it’s more efficient, and understanding the commands will give you a better grasp of how Git works under the hood.

GitWorkflow

Git operates in several key areas:

Working directory (on your local machine)

Staging area (where changes are prepared to be committed)

Local repository (stored in the hidden .git directory in your project)

Remote repository (the version of the project stored on GitHub or other hosting platforms)

Let’s look at the basic commands that move code between these areas:

git init: Initializes a Git repository in your project directory, creating the .git folder.

git add: Adds your files to the staging area, where they’re prepared for committing.

git commit: Commits your staged files to your local repository.

git log: Shows the history of commits.

git push: Pushes your changes to the remote repository (like GitHub).

git pull: Pulls changes from the remote repository into your working directory.

git clone: Clones a remote repository to your local machine, maintaining the connection to the remote repo.

Branching and merging

When working in a team, it’s important to never mess up the main branch (often called master or main). This is the core of your project, and it's essential to keep it stable.

To do this, we branch out for new features or bug fixes. This way, you can make changes without affecting the main project until you’re ready to merge. Only merge your work back into the main branch once you're confident that it’s ready to go.

Getting Started: From Installation to Intermediate

Now, let’s go step-by-step through the process of using Git and GitHub from installation to pushing your first project.

Configuring Git

After installing Git, you’ll need to tell Git your name and email. This helps Git keep track of who made each change. To do this, run:

Master vs. Main Branch

By default, Git used to name the default branch master, but GitHub switched it to main for inclusivity reasons. To avoid confusion, check your default branch:

Pushing Changes to GitHub

Let’s go through an example of pushing your changes to GitHub.

First, initialize Git in your project directory:

Then to get the ‘untracked files’ , the files that we haven’t added yet to our staging area , we run the command

Now that you’ve guessed it we’re gonna run the git add command , you can add your files individually by running git add name or all at once like I did here

And finally it's time to commit our file to the local repository

Now, create a new repository on GitHub (it’s easy , just follow these instructions along with me)

Assuming you already created your github account you’ll go to this link and change username by your actual username : https://github.com/username?tab=repositories , then follow these instructions :

You can add a name and choose wether you repo can be public or private for now and forget about everything else for now.

Once your repository created on github , you’ll get this :

As you might’ve noticed, we’ve already run all these commands , all what’s left for us to do is to push our files from our local repository to our remote repository , so let’s go ahead and do that

And just like this we have successfully pushed our files to the remote repository

Here, you can see the default branch main, the total number of branches, your latest commit message along with how long ago it was made, and the number of commits you've made on that branch.

Now what is a Readme file ?

A README file is a markdown file where you can add any relevant information about your code or the specific functionality in a particular branch—since each branch can have its own README.

It also serves as a guide for anyone who clones your repository, showing them exactly how to use it.

You can add a README from this button:

Or, you can create it using a command and push it manually:

But for the sake of demonstrating how to pull content from a remote repository, we’re going with the first option:

Once that’s done, it gets added to the repository just like any other file—with a commit message and timestamp.

However, the README file isn’t on my local machine yet, so I’ll run the git pull command:

Now everything is up to date. And this is just the tiniest example of how you can pull content from your remote repository.

What is .gitignore file ?

Sometimes, you don’t want to push everything to GitHub—especially sensitive files like environment variables or API keys. These shouldn’t be shared publicly. In fact, GitHub might even send you a warning email if you do:

To avoid this, you should create a .gitignore file, like this:

Any file listed in .gitignore will not be pushed to GitHub. So you’re all set!

Cloning

When you want to copy a GitHub repository to your local machine (aka "clone" it), you have two main options:

Clone using HTTPS: This is the most straightforward method. You just copy the HTTPS link from GitHub and run:

It's simple, doesn’t require extra setup, and works well for most users. But each time you push or pull, GitHub may ask for your username and password (or personal access token if you've enabled 2FA).

But if you wanna clone using ssh , you’ll need to know a bit more about ssh keys , so let’s talk about that.

Clone using SSH (Secure Shell): This method uses SSH keys for authentication. Once set up, it’s more secure and doesn't prompt you for credentials every time. Here's how it works:

So what is an SSH key, actually?

Think of SSH keys as a digital handshake between your computer and GitHub.

Your computer generates a key pair:

A private key (stored safely on your machine)

A public key (shared with GitHub)

When you try to access GitHub via SSH, GitHub checks if the public key you've registered matches the private key on your machine.

If they match, you're in — no password prompts needed.

Steps to set up SSH with GitHub:

Generate your SSH key:

2. Start the SSH agent and add your key:

3. Copy your public key:

Then copy the output to your clipboard.

Add it to your GitHub account:

Go to GitHub → Settings → SSH and GPG keys

Click New SSH key

Paste your public key and save.

5. Now you'll be able to clone using SSH like this:

From now on, any interaction with GitHub over SSH will just work — no password typing, just smooth encrypted magic.

And there you have it ! Until next time — happy coding, and may your merges always be conflict-free! ✨👩‍💻👨‍💻

[serinemisc]

So I came across this recently.

It's funny, because I think I exactly half agree with it. I do rebase-heavy workflows in Git mostly because every single Git client makes merge-based workflows ugly and hard to use. If GitHub simply displayed merges the way it displayed squash-merges, that would eliminate so much of the need for squash-merges.

But I don't think this covers everything. So let me go through every use-case for rebase separately:

git merge --squash

The squash-merge is one of the most popular ways to merge pull requests on GitHub, and it's an abject failure of the Git ecosystem that it's so popular.

When you do a regular merge on a pull request, you are essentially taking a bundle of commits from somewhere else, and putting it on top of your own main branch. It's an extremely linear thing to do.

But if you do that, GitHub's commit log just gets a bunch of commits interspersed throughout, with zero indication where they're from. And the nicer clients, if they do, visualize it as a tree (pronounced "DAG") (pronounced "a huge tangle of curvy lines"):

This pic is from an article telling you to rebase, and, like, sure, rebasing sure is one way to work around a UI that displays your merges as a huge tangle. But Fossil makes a really good point. Why not instead display your merges as, like, not a huge tangle? git log --first-parent does this (and that's clearly an option in that Git UI), but it should be the default everywhere. And even when expanding the "bundle", the bundled commits should still be grouped together, not interspersed with other commits at essentially random.

The other issue is that, when showing the "tangle of commits", the reason it's so tangled is because it's showing the commits in chronological order of when the commits were made. Which is a completely useless sort order, compared to, say, chronological order of when they arrived in the current branch (i.e. grouping the merged-in commits together). This is why GitHub's rebase-merge is also such a popular alternative to merges.

git pull --rebase

Okay, so. Now you've fixed commit log visualization of merged pull requests. But that's not the only use of rebase! Here's another one: if you're working on some code, and constantly keeping it synced with remote, you'll generate tons of merges that are complete useless noise. Unlike a merged PR, these should ideally be hidden completely, or at least nearly-completely.

Anti-rebase people say that these merges serve the functionality of, like, preserving history. You made one commit when the remote was in this state, and another commit when the remote was in that state, and this is sometimes important history to preserve.

I think they are way overestimating how important that history is (judging by how many people use pull-rebase). I'm fine preserving that history if you can declutter the UIs, but it does require your UI to be able to distinguish between "important" merges (of new features from feature branches) and "unimportant" merges (keeping branches in sync with remotes).

The linked post doesn't talk about this problem at all, so I don't know how well Fossil handles this.

git commit --fixup

That leaves the amend/fixup commit. The link does mention that Fossil supports editing past metadata (e.g. commit message). But sometimes you want to edit the actual changes of a commit.

Now, for a sufficiently published commit, this is a bad idea. But if you have a habit of "commit early, commit often", having 50 bugfix commits makes a commit log really cluttered.

I frequently, like, have to weigh stuff like "is it worth cluttering the commit log to fix one typo in one comment?" for old code. And it would really suck to also have to do that for unpublished code, instead of going in with my trusty rebase scalpel.

git that's all I wanted to say

In conclusion. git rebase is a solution to a number of things that could also be viewed as UI problems, and fixed in other, better ways, and Fossil sure sounds like it's fixed some of them. But some of those UI problems are legitimately hard, and I'm not convinced Fossil fixes all of them, and GitHub extremely has not, so I'm gonna keep rebasing.

[neverenoughmarauders]

Please tell me something about "For the dead travel fast" because I am guessing this is a WIP I will like very much 😬

Hello friend! I talked a little bit about it here, and I hope you will like it as it contains your favourite couple AND we even have Fabian (because why wouldn't I throw him in). But this is as good a chance as any to test whether I have captured the complicated mess that is Wolfstar.

'So,' said Sirius casually as Remus closed the door behind him, 'how's James?'

Remus stilled. 

'James?' 

Taking a deep breath, he turned to face his boyfriend.

'Scrawny git, messy hair, wears glasses.'

Sirius' tone was not nearly as light as his words: each syllable laced with impatience.

'What makes you think I've seen James?'

'Come off it,' Sirius snapped, all pretence vanishing. 'Jim crashes the car so that I am stuck here being miserable, and twenty hours or so later, he's still not been here to apologise?'

No, Sirius, I haven't been to see James... because, you see, nobody has seen him. Or Lily.

Remus couldn't get the words out. 

'He's hurt.' 

It came from Sirius, low and certain, as he studied Remus intently.

Remus shivered. The look in Sirius’ eyes was familiar, and yet completely foreign. Cold. Calculated. Dangerous. It was the expression he usually reserved for enemies. 

We don't know. 

Panic clawed its way through Remus as reality forced itself upon him. They had no idea if James or Lily were injured. The thought of admitting as much to anyone, let alone Sirius, was terrifying. It would make everything real, in a way nothing else—not even the abandoned car—had.

'He got out after the crash... I don't know if you remember,' said Remus, carefully. Not because he meant to keep anything from Sirius, but because he still couldn’t find the right words.

'That's not the same thing, which you know.'

Sirius had studied ancient Greek and Latin. He was fluent in words and nuances. Remus' omissions were child's play to him.

Remus let out a breath he did not know he'd been holding. The moment of truth, then-:

'We don’t know.' 

The words tasted wrong even as he said them. There was no good way of telling Sirius this. No gentle version of James is missing. No way to cushion the blow. No reassurance to offer. If there had been, Remus would have clung to them already.

'What do you mean?' Sirius’ brow furrowed. 

Whatever he’d expected, it wasn’t this.

Of course not. No one ever imagines their best friend will vanish. No one thinks this will happen to them. Whatever this was. Abduction? Another accident?

Murder? A question that slithered in, uninvited.

'Nobody has seen James—or Lily—since they stayed behind with the wrecked car.'

'When you say "nobody" -' Sirius started. 

'I mean—nothing, Sirius,' Remus exhaled, exhaustion settling into his bones like frost. 

They were standing at a divide between two lives: the one they had lived, and a new one. Whatever came next, Remus had the horrible sensation that things would never be the same. 

'They've not been in touch... We've been driving up to the scene of the accident: The car is still there, but...'

Remus' voice trailed off.

'So they're just gone? Disappeared into thin air?' 

Remus didn't answer.

Sirius sat up: 'People don't just evaporate, Remus. So what do you and the others think happened? What lines are we investigating?'

Remus swallowed. Sirius really wasn't going to like the next bit either.

'I think you should sit down.' 

The change in Sirius’ tone caught Remus by surprise.

'Sorry?'

'Sit, Remus.'

Despite everything, Remus could hear the affection in Sirius' voice. It was his olive branch. 

Remus sank down, though he chose the sofa, rather than the edge of the bed. He wasn't sure he could be a good partner right now. The space helped keep things clinical, somehow. 

'Gideon reckons there is a chance that James was more injured than he let on—or was able to notice,' said Remus. 'Alice is checking the nearby hospitals.'

'I can believe the "able to notice" part,' Sirius agreed, looking thoughtful. 'That's happened before. But James... Not letting on being injured...' 

The comment was no doubt intended to lighten the mood a little, but it was Remus' turn to frown: 'I know what you're thinking, but there are two circumstances in which he would keep quiet. Both of which were present.'

'Evans, of course.' Sirius shook his head; then grimaced. Probably not the best thing to do with a concussion, Remus thought. But there was no point in saying anything. 

So much for "taking it easy" and "no strenuous" activities.

'Precisely,' agreed Remus.

'And...' Sirius started. 

He closed his eyes for a second as realisation must have dawned. 

'And us.'

'And us,' repeated Remus, his throat feeling tight, the memory of their disastrous Duke of Edinburgh expedition floating to the surface.

James would keep quiet if he was worried about their well-being. Which he would have been.

'Okay, well,' said Sirius. 'That tracks.' 

Except it didn't track. Sirius must have known that as well as Remus did. Why hadn't Lily contacted them, if James was in hospital?

'Any idea when Alice might know more?'

As it turned out, exactly at that moment. 

There was a knock on the door.

'He knows,' said Remus, as he opened it and Alice, Fabian, and Gideon stepped inside.

None of them sat.

Alice was trembling, even if only slightly. Remus had never seen her like this. Neither Fabian nor Gideon put a reassuring hand on her arm—and somehow, that was worse. Whatever they’d found out, it wasn’t good.

None of them met Remus’ eyes.

‘Either James is more injured than you feared,’ said Sirius, his voice deadly calm, ‘or we still have no idea where James and Ev-Lily are.’

Everyone in the room knew Sirius well enough not to be fooled by his tone. This was Sirius at his most lethal. This was Sirius being scared.

There was, of course, a third option for why the three would be acting this way, but not one that Sirius, or Remus, would acknowledge. 

Alice shook her head: 'Nothing. Wherever they are, they're not at a hospital.'

There was more.

[rianavi]

what do you see in her?!

luke castellan x artemis!daughter!reader

start to a series

part 1, part 2, part 3

summary; luke stands up for you

series masterlist

when he first arrived at camp he was a bit scared of you. your stern gaze and biting words, he wondered if you ever laughed.

then during archery he saw you shoot an arrow right into another, that’s when he knew he had to be your friend.

after that, it was as if you couldn’t shake him, he followed you during trainings, sat with you at lunch and campfires, he even begged mr. d to put hermes and artemis cabins together for capture the flag.

when you finally got used to the annoying git, you realized how fun he was to be around. you guys would pick fruits, swim, and make crafts together, he swears he even saw you smile a couple of times.

then when you guys were older and more mature - you more than him - he developed a sort of crush on you. he would hold your hand on walks, comfort you during hard times, and patch you up after rough trainings.

over time you guys grew incredibly close, and you might have even fallen for him too.

you enjoyed the way he made you laugh and smile, the way he would blush slightly when anyone mentioned you two as really close, but you found yourself most drawn to how good of a friend he was to everyone. never leaving out the younger kids or the kids who had trouble making friends. he was sweet to everyone, which is why you found it weird he was so close with you.

you didn’t have many friends and most people ignored you in fear, people constantly asked you why you were mad when you weren’t - cure that resting bitch face -, and most people gave weird looks when you and luke were together.

i mean, how could someone so gentle and kind be friends with someone so cruel and angry. it was if he pitied you for being so weird to other people.

you constantly doubted that he actually liked you, that he actually enjoyed spending time with you.

that was until you overheard him talking with someone.

you were up in a tree, reading your favorite book to escape everyones loud chatter and laughter.

you were meant to meet luke in about an hour to go to the lake so you took the time you had to yourself with an open mind.

all the sudden you hear your name causing you to look down. through the bushy leaves and overgrown branches, you could make out luke and some demeter boy that you briefly recognized as he was quite popular standing and talking.

“i mean, why are you even friends with her, she’s weird. everyone hates her and she doesn’t even try to change our minds.” the demeter boy spoke.

“don’t say that about her. she- she’s not- look man, just because you guys don’t try to actually get to know her and just assume who she is, doesn’t mean that you have to belittle her. it’s not her fault she looks mean, she’s not, she’s actually quite funny and caring. you’re just mad because you can’t win over one person, and she’s better than you could ever be.” luke speaks passively and shoulder checks the boy before stomping off in anger.

it was then that you knew, you had fallen completely in love with luke castellan.

[hostilemuppet]

Brozone & Acquaintances: Fame and Blunders (The Rise And Fall, The Epic Highs And Lows Of Trolltwt) Part Six

split into a new post bc the last one (parts 1-5, crossposted on ao3 (including intermission)) got too long. as always, cowritten by the evil genius @squirrelpatties

cloud guy: infamous leaktwt contributor, with a specific fixation on branch (and to a lesser extent anyone close to branch, but branch is his #1). he got his hands on several embarrassing baby photos of branch, which even jd was concerned about, because "we never published those ones, they were just for grandmas wallet". some of his most well known leaks were "barb was admitted to rehab" "creek got a BBL" and "smidge had a miscarriage" (the latter overshadowing the other two by a significant margin)

sky toronto: egotistical millionaire who bought twitter and changed the logo into a tie. whenever creek posts a new off-the-wall conspiracy theory to his impressionable audience, sky replies that hes "Looking into this..." (theyre oomfs). many of his experimental party supplies have killed a disgusting amount of animal test subjects but that doesnt mean hes not willing to test on trolls. branch almost dies when hes hit by someones neuro-mind-link party popper.

smidge vs barbtwt: several influential barbtwt members with a tie to a certain infamous leaker who shall not be named (they paid him. he didnt need the money he just likes messing with people) get their hands on smidges medical records, initially to prove shes trans (shes not) but they instead learn about her miscarriage. instead of backing off, showing her sympathy and feeling guilty about this disgusting breach of privacy, they coordinate to make this public knowledge the next time smidges name trends. twitter is divided into "smidgetwt supporting her wholeheartedly through this horrible situation" "smidge antis who think 'she had it coming'" and "barbtwt happy that smidge is suffering". this sparks a debate on the ethics of trolls smoking while with eggs, with pro-egg-smokers saying its their body their choice and anti-egg-smokers saying "are you out of your damn mind". this is how smidge reveals she is simultaneously pro-egg-smoking and pro-life. its a bloodbath. she drops off the face of the internet never to be seen again........ unless 🤔

cloud guy (part 2): after years of providing the public service of "making branchs life miserable", cloud guys twitter account (and IP) is sadly permabanned when poppy demands sky toronto take action the third time branch is doxxed. sky toronto originally didnt care but after a solid week of her pestering him, he gave up, but only because he forgot to take "no doxxing" out of troll twitters TOS, and the backlash would be worse than hes willing to deal with right now. sleep well, soldier 🫡.

dante vs poppy: dante is branchs stalker. routinely stakes out by branchs pod to take photos of him for his shrine. its not a sex thing but whatever it is is way weirder than a sex thing. branch has moved pods 3 times but dante always manages to find him. perhaps he has friends in high places? regardless of the "how", the "what" is poppy wants him fucking Gonezo. unfortunately dante, as an ambassador for classical trolls, is not under poppys jurisdiction of pop trolls. she decides the only way to deal with the "rando stalking my partner" situation is to catch him with one of branchs traps. except, dante can fly, so rope traps arent effective and poppy needs to get creative and potentially very violent. she asks branch if he still has those spikes she begged him to take down. he does but he repurposed them as hat racks. now he needs to find somewhere else to put his hats!

gus tumbleweed: lowtiergod-esque fighting game streamer whos known for yelling and screaming at his opponents when he loses. he goes into long, drawn out, nonsensical similes and metaphors to describe how much he wants the player who beat him to kill themself or otherwise die painfully

tiny (in game chat): git rekt f4gg0t gus (on mic): someone outta hog tie ya and hang ya up in the middle o town like a pinata caught sleezin with the mayors daughter tiny (in game chat): bro

is invited to take part in a tournament for charity during pride month. when beaten by a gay guy he regresses to violently homophobic hatespeach. youd think thisd be a career ender but its amazing what "pretending to be attracted to your fellow straight male friends" can fix! he makes a halfhearted comment about thinking one of his streamer friends is handsome and/or has a nice ass and everything is back to normal, and he faces zero consequences for his actions.

holly darlin: fellow twitch streamer, although in different circles to gus tumbleweed. she is undefeated at chess but otherwise unremarkable, yet because shes a woman everyone hates her. after a year or two or constant hate she decides "fuck it" and commits to selling snake oil. the hell are they gonna do? call her a whore? shes already got every variation and misspelling caught in autofilter, buddy. she peddles for the same company that supplies the diet pills satin and chenille hype up on their podcast. its how she and satin meet. theyre lesbians now. it makes the hate holly gets SOOOOOO much worse but satins used to it so shes unaffected. chenille gets no say in the matter

synth: third and final twitch streamer (...so far). the gay guy who beat gus in a tournament for charity and was met with violent hatespeach. beforehand was one of the smaller creators in the tournament but afterward he blew up a lot more. he does a lot of charity streams, mostly for the benefit of disabled children, out of the goodness of his heart and NOT the glory like some OTHER trolls mentioned two paragraphs previous. hes just a good guy! also almost had a thing with branch when they were both confused about each others identities.

synth: today marks a year since i almost kissed a very attractive twunk in pop village and then found out he was a lesbian who thought i was a lesbian minuet: gay culture

broppy: theyre doing great! absolutely NO problems whatsoever! im sure it will last forever!

[moose-mousse]

A beginners guide to GIT: Part 4 - How to use GIT as 1 person

Table of content: Part 1: What is GIT? Why should I care?

Part 2: Definitions of terms and concepts

Part 3: How to learn GIT after (or instead of ) this guide.

Part 4: How to use GIT as 1 person

Part 5: How to use GIT as a group.

When it comes to not getting in each other's way, working alone is the simplest (It has a lot of other drawbacks). This is the simplest way to use GIT. You can do it with an external repository as a backup or just locally on your computer. It depends on how important your project is. If your laptop crashes tomorrow, which projects would you have a really hard time losing? Better to have an external backup for that. Github is often used for this (Maybe less now that Github makes machine learning AI’s, and so ARE stealing your code to train their AI on.) but you can also use Bitbucket (Which... may also steal your code...) and there are many many others out there. GIT is often used in certain patterns, called “workflows”. These have you working in more or less rigid ways to make it simple to work together. But since you are working alone, you do not risk others changing your code while you are working, so you can do it the simplest way :D

I will be doing a step by step guide that you can follow along. I will be doing it on a completely empty project and making a tiiiiiny program in C. This is because it is super simple. You do NOT have to know C to follow. You can also follow the steps with your own already existing project.

I PROMISE you, GIT cannot hurt you. Worst case scenario is that you fiddle around and break the repository part. (Meaning the files in the .git folder). But your files will always be safe.

(If you do not have git installed, check out part 3 for that)

First, I make a folder, navigate my shell into it, and call git init:

By the way, you can get used to GIT messages like this that tell you all your options, and explain what GIT has done for you. GIT is very good about giving you as much help and info as possible,

Now I will teach you the most important command in GIT.

It is more important than any other. Ready?

git status

This makes GIT tell you what git thinks is happening right now. What issues there are and what files are tracked, untracked or have been changed. Use this command often, especially while you are new to GIT, run it after every other command. It is how you learn what GIT is doing and thinking :3

Since our repo is empty it tells you what branch you are on (master. The only branch we will need since we are working alone)

and that you have not made any commits.

It also tells you the commands git think you will want to use on files. Since our repository is empty, it tells us to create some files, and then how to add them :3 So let's do that:

I have added my tiny program, as you can see:

Now let us see what GIT thinks we did:

Now, since there have been changes, git shows us them.

Files can be untracked tracked and not changed (In which case, git status does not show them) tracked and changed.

Right now, main.c is untracket. Which basically means GIT have no idea about this file, other than it is in the folder.

Ok, let us commit(save) the file. GIT tells us this is done with git add <File> . So we will write git add main.c

Then we use git status again to see what happened git status

And yeah, our file is now ready to be committed. So lets do it! git commit -m “My first commit!”

The “-m” option is to write the git update explanation directly in the console instead of using an external program to do it. Done You have now committed your code! It is now saved!

git status shows that everything in the working tree is as it was last time we committed (Duh. We JUST committed)

I will now make some changes to the main file:

Git status shows us main.c was changed...but what if we wanted to know what was changed in more detail? How will we get status to do that for us? Let us find out! git help status

git then shows the help page for status And there we can see this part:

So if we write status with 2 -v arguments, we get all the details. Let us try:

And look! It shows us EXACTLY what lines were changed! I stage the changes and commit:

And you have now learning enough about GIT to use it.. You now have all your work saved, in different commits. If you ever want to know all the commits you have made, write git log:

And if you want to know what a specific commit did, you copy the name of the commit, and write git show:

Now, everytime you want to save your work, you

1: Write/change the files you want

2: Add the files you want as part of this commit

3: make the commit These three steps are your workflow.

If you have a remote repository, then you add them steps

4: push to remote repository

To do this step, you can actually just write

git push

If you have set up a remote repository, then it just works. If you have not, then git will tell you what to do Whichever remote repository you use will tell you if you need to do other steps, like setting up passwords or ssh keys. They will also tell you how to set up the remote repository (That is not a GIT thing, that is a bitbucket or a github thing, so refer to whichever of those sites you want to use) And that is all! Every time you commit, your project is saved (it is smart to commit often, but usually only commit when your project can be compiled.) And whether you use a remote repository or not, you now have a fully valid GIT repository, and all the git tricks can be used on your project!

[wayfire-official]

does anyone know how to nicely manage dark/light mode stuff in dotfiles? like, some universal way to change what config file is used?

i currently have a second branch where i have light mode configs, but tbh it's kinda bothersome. in theory i could just do git checkout and all the files get switched, but things such as my wayfire.ini are difficult to keep updated on both branches, so my main branch is behind

[transienturl]

this is, obviously, the kind of thing you ideally never use, and thus probably shouldn't really know?

however: I finally bothered to figure out how to use git rebase --onto to sync changes between multiple git branches that depend on one another.

normally, one runs git rebase [new base branch] to change the base of the the currently checked out branch to the target. typically this is git rebase main or git rebase master. there's a second argument that can go after the new base branch that defaults to the currently checked out branch; that argument makes following the documentation/examples I could find confusing and I always check out the branch I'm working on so I'm going to ignore it.

the --onto argument takes two inputs: the first is the same as the regular argument; the second is the last commit on the current checked out feature branch we want to drop because it is now obsolete.

I think the way git diagrams usually show branches is unhelpful here; here's mine. say I have this:

A---B---C---D feature1 A---B---C---D---E---F feature2

I realize that I have a bug in commit C in feature1, and the fix will merge conflict with D. I rewrite history on feature1 to fix it:

A---B---C*--D* feature1 A---B---C---D---E---F feature2

now I check out feature2, wanting to update it. I can't just do git rebase feature1, because git will try to make A---B---C*--D*--C---D---E---F. I can make a temporary branch based on feature1, cherry pick E and F onto it, then hard reset feature2 to the temporary branch, but that's silly. (I could probably do a number of other things; there are like eleven billion git commands. please comment if you know an even better way to do this.)

what I want to do here is git rebase --onto feature1 D (where D is the sha of commit D, the last commit I do not want to keep on feature2 because I am replacing it with the new base branch).

I have no idea why this command is not git rebase feature1 --onto D or something. replacing the first argument you would normally use with a flag and then the argument you would normally use and then another different argument makes precisely zero sense? but, whatever, fine. sure wasted me a lot of time in between the first time I read that manpage, gave up, did temporary branches for years, then finally figured it out, but you do you, git devs.

edit: oh, this probably goes without saying if you know enough git to read this, but this is only necessary if one does rewrite history on feature1. if you just commit a fix on it normally, git rebase feature1 (and then handling any merge conflicts in E and F) will work fine. that's why you generally don't need to know this; it's only necessary if you're manipulating your commit history because you think it'll provide useful clarity and think that's worth the complexity in your git workflow. I do it a fair amount because I tend to juggle multiple potential changes to the same code at once more than is probably wise, but I definitely lean toward not doing it, particularly in a codebase that uses squash merging for PRs and discards all of this history in the end anyway.

[wizardingworldlibrary]

Jealous!Harry Masterlist

Alone Again, Unnaturally (ao3) - Seekerofknowledge3119 hermione/harry T, 18k

Summary: What happens to a sensitive teenage boy when their best friend doesn’t contact him for a whole summer and seems to be losing touch with him?

You get this story.

AKA: What if Harry reacted differently to the Order keeping him in the dark in his fifth year?

An Exercise In Forgiveness (ao3) - Animamundi draco/harry, hermione/ron M, 74k

Summary: Seven apologies in seven years.

A down and out Draco is on a quest to become a better man while trying to find his moral compass. Meanwhile, Harry struggles with regret and resentment and is unable to leave the war behind.

Can they find Grace and forgiveness? A story of redemption, food, friendship, love and forgiveness.

Ballad of the Mantis (ao3) - Tessa Crowley (tessacrowley) draco/harry E, 27k

Summary: Officially, the codenames of those who work for the espionage branch of the DMLE are assigned randomly, but twice in a row, Draco Malfoy’s codenames have been insects—and not just any insects, but insects with cannibalistic tendencies. Perhaps it should be taken as a compliment. After all, who better to tear down a splinter cell of Death Eaters than one who eats their own?

Bloody Business (ao3) - IlliterateBastard draco/harry E, 10k

Summary: Harry stumbles onto Draco Malfoy who had vanished from the Wizarding World, looking as fit as ever, behind the bar of a Muggle club, nonetheless. He consequentially becomes rapidly obsessed with him-again.

'Cause He's So Hard To See (ao3) - dexterbird hermione/harry M, 42k

Summary: "Am I good-looking?"

"What's this?"

"You know, am I like handsome?"

The summer before sixth year, Harry Potter discovers he's fanciable. He proceeds to have an existential crisis.

Change the Ending (ao3) - fanfairmod, Kaymardsa draco/harry E, 54k

Summary: When Draco gets hit by a curse that makes him essentially allergic to magic, Harry takes him in as a favour to Ron and Kingsley to teach him how to survive without it while they wait for a cure.

Cherry Chapstick (ao3) - scudeliwu draco/harry N/R, 3k

Summary: Luna founded a LOVE-club which Hermione and Draco accidentally join. Now that they are committed to act non-violently, instead of punching Ron, Draco kisses him square on the mouth. Harry’s jealous, that he doesn’t get to taste Dracos cherry lips, too.

chosen (ao3) - Anonymous draco/harry G, 1k

Summary: “if astoria comes back, tell her to piss off and find a new apothecary.”

draco laughed against his lips. “i cant do that, you git.”

Forever (ao3) - Chemical_Raspberry hermione/harry E, 4k

Summary: Harry plans to confess his feelings for Hermione on the night of Slughorn's Christmas party. When an old friend of hers shows up unexpectedly, however, he is not pleased.

Magnificent (ao3) - UnicornSward hermione/harry M, 4k

Summary: When the entire Puddlemere United team starts expressing a sudden interest in Hermione, Harry, always the protective best friend, begins to realize that his teammates aren’t the only ones drawn to her like a magnet.

move fast, keep quiet (ao3) - cloudings draco/harry E, 8k

Summary: Harry and Draco aren’t very good at using their words. Eye contact works for a while, until hands and mouths work considerably better at getting their points across.

on the divine agony of longing (ao3) - flimsy draco/harry E, 25k

Summary: Draco’s eyes narrow and his mouth purses, pretty and pink and wet from whatever he’s been drinking. “Any mediocre time is better than whatever you can you offer, Head Auror Potter. We’ve had this conversation. I thought I made myself clear.”

Our secret place (ao3) - louaylor_stan (hauntedwalls) draco/harry G, 3k

Summary: Harry and Draco have been friends for years. They have both reached a point where they must confront their feelings.

Rejecting Ginny Weasley (ao3) - Vaffyu harry/ginny, hermione/ron T, 43k

Summary: Harry and Ginny share a friendly dance at the Yule Ball, much to the amusement of the Gryffindor boys, who tease Harry mercilessly. Harry, panicked, screams that he would never date Ginny Weasley, only for the girl to overhear.

A year or so later, Harry will come to realise just how much he regrets rejecting Ginny Weasley.

Spark (ao3) - Kristinabird draco/harry G, 1k

Summary: Harry and Draco have decided to separate.

Thank you Shakespeare (ao3) - Merrinpippy harry/tom T, 2k

Summary: Harry looked up from his comfortable position in his armchair to find Tom staring at him once again, an indecipherable look on his face. He hoped Tom wasn’t still angry with him, but Tom kept staring at him with that intense look of his, and Harry didn’t know what it meant.

So yes. Evenings in the Room of Requirement. With Tom. Who Harry certainly wasn’t harbouring deeper feelings for. At times like these, Harry felt like a damned masochist.

White Hot Hatred (ao3) - DarkLordDraco draco/harry E, 5k

Summary: Draco and Harry are forced to share a room for the year. They decide to make nice. Maybe a little too nice.

Will You Be Mine? (ao3) - Ayessel hermione/harry E, 4k

Summary: Hermione is ignoring Harry due to an argument in 6th year and Harry gets jealous that she's starting to talk to other people and be happy without him. When Hermione starts another argument up it comes to light that Harry's been harbouring feelings for her for years that he kept locked away because he didn't think she liked him back.

tl;dr An argument that leads into possessive, rough sex that Hermione thoroughly enjoys. With some emotional bits sprinkled in because I'm sappy

[govindhtech]

What is Argo CD? And When Was Argo CD Established?

What Is Argo CD?

Argo CD is declarative Kubernetes GitOps continuous delivery.

In DevOps, ArgoCD is a Continuous Delivery (CD) technology that has become well-liked for delivering applications to Kubernetes. It is based on the GitOps deployment methodology.

When was Argo CD Established?

Argo CD was created at Intuit and made publicly available following Applatix’s 2018 acquisition by Intuit. The founding developers of Applatix, Hong Wang, Jesse Suen, and Alexander Matyushentsev, made the Argo project open-source in 2017.

Why Argo CD?

Declarative and version-controlled application definitions, configurations, and environments are ideal. Automated, auditable, and easily comprehensible application deployment and lifecycle management are essential.

Getting Started

Quick Start

kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

For some features, more user-friendly documentation is offered. Refer to the upgrade guide if you want to upgrade your Argo CD. Those interested in creating third-party connectors can access developer-oriented resources.

How it works

Argo CD defines the intended application state by employing Git repositories as the source of truth, in accordance with the GitOps pattern. There are various approaches to specify Kubernetes manifests:

Applications for Customization

Helm charts

JSONNET files

Simple YAML/JSON manifest directory

Any custom configuration management tool that is set up as a plugin

The deployment of the intended application states in the designated target settings is automated by Argo CD. Deployments of applications can monitor changes to branches, tags, or pinned to a particular manifest version at a Git commit.

Architecture

The implementation of Argo CD is a Kubernetes controller that continually observes active apps and contrasts their present, live state with the target state (as defined in the Git repository). Out Of Sync is the term used to describe a deployed application whose live state differs from the target state. In addition to reporting and visualizing the differences, Argo CD offers the ability to manually or automatically sync the current state back to the intended goal state. The designated target environments can automatically apply and reflect any changes made to the intended target state in the Git repository.

Components

API Server

The Web UI, CLI, and CI/CD systems use the API, which is exposed by the gRPC/REST server. Its duties include the following:

Status reporting and application management

Launching application functions (such as rollback, sync, and user-defined actions)

Cluster credential management and repository (k8s secrets)

RBAC enforcement

Authentication, and auth delegation to outside identity providers

Git webhook event listener/forwarder

Repository Server

An internal service called the repository server keeps a local cache of the Git repository containing the application manifests. When given the following inputs, it is in charge of creating and returning the Kubernetes manifests:

URL of the repository

Revision (tag, branch, commit)

Path of the application

Template-specific configurations: helm values.yaml, parameters

A Kubernetes controller known as the application controller keeps an eye on all active apps and contrasts their actual, live state with the intended target state as defined in the repository. When it identifies an Out Of Sync application state, it may take remedial action. It is in charge of calling any user-specified hooks for lifecycle events (Sync, PostSync, and PreSync).

Features

Applications are automatically deployed to designated target environments.

Multiple configuration management/templating tools (Kustomize, Helm, Jsonnet, and plain-YAML) are supported.

Capacity to oversee and implement across several clusters

Integration of SSO (OIDC, OAuth2, LDAP, SAML 2.0, Microsoft, LinkedIn, GitHub, GitLab)

RBAC and multi-tenancy authorization policies

Rollback/Roll-anywhere to any Git repository-committed application configuration

Analysis of the application resources’ health state

Automated visualization and detection of configuration drift

Applications can be synced manually or automatically to their desired state.

Web user interface that shows program activity in real time

CLI for CI integration and automation

Integration of webhooks (GitHub, BitBucket, GitLab)

Tokens of access for automation

Hooks for PreSync, Sync, and PostSync to facilitate intricate application rollouts (such as canary and blue/green upgrades)

Application event and API call audit trails

Prometheus measurements

To override helm parameters in Git, use parameter overrides.

Read more on Govindhtech.com

[ya-boi-haru]

I lied, put your clothes back on,

I'm about to go on an essay ramble about one of the concepts for my OCs story ('Ingress')

'Ingress' contains characters from various different worlds with different beliefs, government structures, species and an almost endless possibilities of abnormal powers.

While there are hundreds, if not thousands of possible abilities people can have, you can always categorize it down to one of two things: Genetic and Gifted.

Simply, Genetic power is where is passed on through blood, something you were born with, where as Gifted is where you obtain the power via a 3rd party, (Gods, cursed, abnormal incidents etc)

Does this affect the strength and limit in which a person can use their power compared to the other type? No. One of - if not the main - arc of 'Ingress' is that blood and labels do not define your limit, your limits are what you set for yourself.

So then how does it compare?

Imagine you have a rose bush. Tend to this bush and the flowers will bloom full and beautifully. However, If you were to cut off all the roses, one would argue that's its not a rose bush anymore, cause it doesn't have any flowers. But, it *is* a rose bush, it's designed to grow more roses over time, so it never stopped being a rose bush.

This is a metaphor for Geneticly powered people.

Genetically powered have this power running in their viens, it *is apart of them*. There a concepts and a few moments I wish and hope to explore where you can actually see that it is them.

To strip a G.P person of that ability would be excruciating, literally tearing them apart at their core.

Buts that's not to say that would be the end of it. As people we are constantly growing and even growing new cells every single day and it's still us, *our* DNA, it never changes. So while you have have stripped a Genetic Powered person's powers away, it will actually grow back over time. It may take an entire life time, he'll, it may never be the same as it was, but ut will return eventually. You can cut off every rose on the bush, but the plant is designed to grow more.

Now instead of a rose bush, imagine just a regular, leafy bush. However, you really want this bush to have flowers, so you just add your own into the bush. Now over time, the branches may learn to form around and connect to the flower and it'd basically be a flowering bush. But if you take all those flowers off, It won't flower on its own. It's just a regular bush again.

This is a metaphor for Gifted Powered people.

When a person is gifted (or cursed, blessed etc) their body fuses with the gift and it becomes them. To strip them of that is also excruciating, but it will never come back to them naturally, they will have to repeat the events in which they git it to get it back.

Throughout my wip story, I also want to play with devices that can neutralise an ability. (Similar to the collars in X-Men). With these it would effect a Genetic person more than a Gifted.

The devices would be cancelling out something that wasn't "human", with a Gfited person you could seperate the two easily, as it would be like separating two coloured pens. For a Genetic person it would have a bit more effect, some causing to pass out and sometimes even staying out until the device has been turned off/removed, as this would be like separating colour from coloured water.

Another fun concept is one OC in particular who has both Gifted and Genetic abilities.

From the top of my head, this is the only oc I have so far in this world that has both. Not to say that having both is rare, but it's not that greatly common either.

His genetic ability is Energy manipulation and his gifted power is teleportation. Over time he learned to use one power to help the other. His teleportation allows for him to 'jump' anywhere he wants (he has to have a visual on where he's going) however the greater the distance the more energy/stamina it drains him of. He's also learned that he can siphon energy off another person or thing - though it has to be a specific kind, mainly the type that's of his original world - and he uses this to give himself more strength and fuel the teleportation. While off his world, he doesn't have access to the specific energy he needs and eventually learns over time that he can use himself.

Again, he *is* of his world and energy and is constantly growing and his body is unconsciously giving out more energy, so he siphons off himself, almost in a funny image plugging an extension cord into itself. He can't do it for great lengths and does still need to rest, but it does get him around.

Now, if a Gifted person were to have a child, it is possible they could also get the power and it then becomes genetic to the child. Whereas if abilities are a genetic thing a child is almost guaranteed to get an ability from a Genetic parent.

I have OCs in worlds where getting gifted abilities is extremely common. I have OCs in a world where being Geneticly powered is part of their religion. I have OCs in worlds where Gifted abilities are unique to each, but their limits are what the set for themselves!

-

I hope this made sense and thank you for reading my ramble

Will I do more? Idk I just love my blorbos and am still working out the world building, I just love this concept so much-

[snaildotexe]

so instead of actually buckling down yesterday and prepping for my OA for this internship, I procrastinated even more by *spontaneously deciding to host my webapp* 😭😭

see it at anisa.tech (i love my domain name so much i think its so cool!!!)

Quick demo:

Study Time/Focus Time/Proportional Pomodoro (can't decide on a name) is a sort of Pomodoro style timer, except you have the option to focus for longer (or shorter) than 25 minutes, and when you decide to have a break, it will be proportional (25:5) to the amount of time you focused for. So if you work for 40 minutes it'll give you an 8 minute break. But you can also do a set break if you don't want the proportional break. I also just like knowing exactly how long i was working, which is why i added the total time when you extend your timer.

I built this because I love using pomodoro timers, but I sometimes get so focused and skip my 5 minute breaks, or even skip the long breaks. I'd end up working for a couple hours straight and when I'm finally ready for a break, it gives me a 5 minute break 😑 So then I'm like, "no way, im taking a longer break" but then I take a several hour long break and feel bad for taking too long of a break.

It's not completed by any means, theres a couple bugs still and TONS of features i still wanna add. Like adding the long breaks, or the option to change the focus:break ratio. And dark mode. But its functional for the most part, at least for my purposes. **Edit: oops actually I forgot I the functional code is in a branch that I wanted to clean up before merging to master, so the actual functioning version of the timer is not what's being shown on my site. I'll get that fixed soon.

honestly i only decided to host it yesterday because i actually use this timer a lot, and im tired of having to open vsCode and launching Live Server lol. I'm hosting using aws S3, which is free (or free for 1 year, idr) but that's why there's that long chain after my domain. If i knew it was gonna add all of that i probably would have just payed the $20 for a year of hosting somewhere else lol. Also using Deployhq to update the site after a Git push.

anyway check out anisa.tech if you like productivity timers :)

[transcuratorsblog]

How Web Development Teams Use Git and Version Control for Efficiency

In the fast-paced world of web development, every change, update, and line of code matters. Managing all that effectively—especially across large teams and complex projects—requires more than just good coding skills. It demands version control, and more specifically, a robust system like Git.

Git has become the industry standard for version control, allowing teams to collaborate, experiment, and deliver changes faster and with fewer mistakes. When you work with a Web Development Company, Git is almost always part of the workflow—because without it, efficiency and collaboration would take a serious hit.

What Is Git and Version Control?

Version control is a system that tracks changes in code over time. It lets developers manage, review, and roll back code modifications without losing previous work. Git, the most popular version control system, is a distributed version control tool that enables multiple developers to work on the same project simultaneously without overwriting each other’s work.

Git helps teams:

Track every change to the codebase

Collaborate seamlessly without conflict

Roll back to previous versions when bugs arise

Experiment safely with new features in isolated branches

It’s like having a rewind button for your website’s development.

Why Git Matters in Web Development Projects

Without version control, managing multiple developers, features, bug fixes, or updates becomes chaotic. Git allows web teams to move quickly and confidently, knowing their work is secure, reversible, and organized.

Let’s explore how professional development teams use Git to streamline efficiency:

1. Branching for Organized Workflows

One of Git’s most powerful features is branching. Teams create branches to work on different features or fixes independently from the main codebase (often called the main or master branch).

For example:

feature/blog-module – a new blog feature

hotfix/login-bug – urgent bug fix in login flow

test/ui-improvements – design changes being tested

This approach prevents unfinished or unstable code from affecting live environments, allowing multiple developers to work in parallel without stepping on each other’s toes.

2. Collaboration Without Conflict

Git allows teams to merge code cleanly and manage conflicts through pull requests and code reviews. Before merging any feature or fix into the main branch, developers:

Submit a pull request (PR)

Get peer review and approval

Run automated tests

Merge only when it’s stable

This ensures clean, reviewed, and tested code is integrated into production, improving both team collaboration and code quality.

3. Rollbacks and Issue Tracking

Mistakes happen. A new feature might introduce a bug, or a deployment may not go as planned. Git makes it easy to roll back to a previous version of the codebase in seconds.

With clear commit histories and tags for each release, developers can:

Identify where issues were introduced

Revert problematic commits

Deploy stable versions quickly

This level of control is critical for businesses relying on uptime and smooth user experiences.

4. Continuous Integration and Deployment (CI/CD)

Modern development teams use Git in combination with CI/CD tools like GitHub Actions, GitLab CI, Jenkins, or CircleCI. These tools monitor the Git repository for changes and:

Automatically run tests

Deploy updates to staging or production

Alert teams to errors or failed builds

This automation reduces manual work, speeds up development cycles, and ensures reliability—making Git a foundational part of the DevOps toolchain.

5. Documentation and Accountability

Every commit in Git includes a message detailing what changed and why. This creates a clear audit trail that documents:

Who made changes

What was changed

When and why it happened

This not only helps with team accountability, but also improves onboarding for new developers who can understand the evolution of the codebase by simply reading commit history.

6. Secure, Distributed Workflows

Because Git is a distributed version control system, every developer has a full copy of the codebase. This:

Improves collaboration across remote teams

Ensures backups of the entire repository exist on every machine

Allows work to continue even if the central server is down

In a world of hybrid and remote teams, this distributed structure is critical to efficiency and resilience.

Conclusion

Git and version control are the backbone of modern web development workflows. They bring structure, safety, speed, and collaboration to even the most complex projects. Whether you’re launching a simple landing page or a multi-layered web application, proper version control ensures that progress is smooth and mistakes are reversible.

If you're working on a growing project or scaling your development team, partnering with a Web Development Company that leverages Git effectively can dramatically improve delivery timelines, code quality, and development efficiency. It's not just about writing good code—it's about managing it smartly.

[vijaysethupati]

Top 5 Technologies Every Full Stack Development Learner Must Know

In today’s rapidly evolving digital landscape, Full Stack Development has emerged as a highly valued skill set. As companies strive to develop faster, smarter, and more scalable web applications, the demand for proficient full stack developers continues to grow. If you're planning to learn Full Stack Development in Pune or anywhere else, understanding the core technologies involved is crucial for a successful journey.

Whether you're starting your career, switching fields, or looking to enhance your technical expertise, being well-versed in both front-end and back-end technologies is essential. Many reputable institutes offer programs like the Java Programming Course with Placement to help learners bridge this knowledge gap and secure jobs right after training.

Let’s dive into the top 5 technologies every full stack development learner must know to thrive in this competitive field.

1. HTML, CSS, and JavaScript – The Front-End Trinity

Every aspiring full stack developer must begin with the basics. HTML, CSS, and JavaScript form the foundation of front-end development.

Why they matter:

HTML (HyperText Markup Language): Structures content on the web.

CSS (Cascading Style Sheets): Styles and enhances the appearance of web pages.

JavaScript: Adds interactivity and dynamic elements to web interfaces.

These three are the building blocks of modern web development. Without mastering them, it’s impossible to progress to more advanced technologies like frameworks and libraries.

🔹 Pro Tip: If you're learning full stack development in Pune, choose a program that emphasizes hands-on training in HTML, CSS, and JavaScript along with live projects.2. Java and Spring Boot – The Back-End Backbone

While there are many languages used for back-end development, Java remains one of the most in-demand. Known for its reliability and scalability, Java is often used in enterprise-level applications. Learning Java along with the Spring Boot framework is a must for modern backend development.

Why learn Java with Spring Boot?

Java is platform-independent and widely used across industries.

Spring Boot simplifies backend development, making it faster to develop RESTful APIs and microservices.

Integration with tools like Hibernate and JPA makes database interaction smoother.

Several institutes offer a Java Programming Course with Placement, ensuring that learners not only understand the theory but also get job-ready skills and employment opportunities.

3. Version Control Systems – Git and GitHub

Managing code, especially in team environments, is a key part of a developer's workflow. That’s where Git and GitHub come in.

Key Benefits:

Track changes efficiently with Git.

Collaborate on projects through GitHub repositories.

Create branches and pull requests to manage code updates seamlessly.

Version control is not optional. Every developer—especially full stack developers—must know how to work with Git from the command line as well as GitHub’s web interface.

🔹 Learners enrolled in a full stack development course in Pune often get dedicated modules on Git and version control, helping them work professionally on collaborative projects.

4. Databases – SQL & NoSQL

Full stack developers are expected to handle both front-end and back-end, and this includes the database layer. Understanding how to store, retrieve, and manage data is vital.

Must-know Databases:

MySQL/PostgreSQL (SQL databases): Ideal for structured data and relational queries.

MongoDB (NoSQL database): Great for unstructured or semi-structured data, and widely used with Node.js.

Understanding the difference between relational and non-relational databases helps developers pick the right tool for the right task. Courses that combine backend technologies with database management offer a more complete learning experience.

5. Frameworks and Libraries – React.js or Angular

Modern web development is incomplete without frameworks and libraries that enhance efficiency and structure. For front-end, React.js and Angular are two of the most popular choices.

Why use frameworks?

They speed up development by offering pre-built components.

Help in creating Single Page Applications (SPAs).

Ensure code reusability and maintainability.

React.js is often preferred for its flexibility and component-based architecture. Angular, backed by Google, offers a full-fledged MVC (Model-View-Controller) framework.

🔹 Many students who learn full stack development in Pune get to work on live projects using React or Angular, making their portfolios industry-ready.

Final Thoughts

To become a successful full stack developer, one must be comfortable with both the visible and behind-the-scenes aspects of web applications. From mastering HTML, CSS, and JavaScript, diving deep into Java and Spring Boot, to efficiently using Git, managing databases, and exploring modern frameworks—the journey is challenging but rewarding.

In cities like Pune, where tech opportunities are abundant, taking a structured learning path like a Java Programming Course with Placement or a full stack bootcamp is a smart move. These programs often include real-world projects, interview preparation, and job assistance to ensure you hit the ground running.

Quick Recap: Top Technologies to Learn

HTML, CSS & JavaScript – Core front-end skills

Java & Spring Boot – Robust backend development

Git & GitHub – Version control and collaboration

SQL & NoSQL – Efficient data management

React.js / Angular – Powerful front-end frameworks

If you're serious about making your mark in the tech industry, now is the time to learn full stack development in Pune. Equip yourself with the right tools, build a strong portfolio, and take that first step toward a dynamic and future-proof career.

[moose-mousse]

A beginners guide to GIT: Part 5 - How to use GIT as a group.

Table of content: Part 1: What is GIT? Why should I care?

Part 2: Definitions of terms and concepts

Part 3: How to learn GIT after (or instead of ) this guide.

Part 4: How to use GIT as 1 person

Part 5: How to use GIT as a group.

For this, I will describe a workflow, called “feature branch workflow.” There are others that are simpler, and are sometimes better,  but I will describe one that always works, for any amount of people, and most likely is what your future workplace uses.. And yes, it involves branching (which sounds scary, but it is not so bad.)

Why? Well because of 2 goals we have that somewhat clash.

1: To use GIT in a way that is easy on ourselves and will give us all the benefits of GIT. This means committing often. Pretty much every time we have made a change, and we can compile.

2: We want to sync our work with our fellow workers. But this takes effort every time we do it because we might have made changes that clashes with changes someone else have made.

(Notice though that this is not a problem originating in GIT. This is a problem that comes from people working together on the same thing. GIT just makes it easy to spot the problems and describe them in an accurate way.)

We alleviate this by only syncing up when we have made a larger chunk of self contained work. Usually we use  the term "feature" for this. And they can be quite small (For example 4 commits, making a "Return to previous page" button ) or large (For example,  38 commits, which also used branches, to implement a GUI on top of the backend code we have made).

It is best to make features as small as you can, so that a feature branch does not end up being an entirely different sister project to the main branch.

The first thing we do is declare the main/master branch holy. Just like any branch, it must always compile, but now we add " May only have fully realized features". It must ALWAYS be ready to be shown to the customer/your boss/your adviser/your teacher.

So when we want to do some work, we coordinate it with our teammates so people are not working on the same thing, and thus wasting their time. ( This can be done with tickets, verbally at meetings, in group chats. Whichever fits your team )

Then we make a branch with its base at the tip of the main/master branch. We then do work, commit and push every commit onto that branch. This has all the benefits we had from working alone. We cannot get merge conflicts, as we are the only one working on this branch.

So let us show how this works! For this example I have set up a remote repository on bitbucket containing only a standard README that I have not written in at all., I then cloned it down in 2 different directories. Each of which I have opened with a console. This is how I will represent multiple people:

So first, we show off one person making a change, and the other getting it. So I add a main.c file in there, add it so it is staged for commit, and then commit it:

And if we write git status, we can see that we are 1 commit ahead of the remote repository:

We then push our commits to the remote repository:

The other user can now use git fetch (Which gets the latest information from the remote repository, but does not change anything):

We then pull the latest update from the remote repository with git pull:

This is the simple way to work. But of course, if we have changed the same file, we will get a merge conflict.

As we talked about, we will minimize those by using branches. So we will say that each of these two people now will work on a different feature. Each of which will be a function that prints something. And each will be in another c file, with a header. We will do this with branching. We want to make a branch, and then switch to it. Switching to branches is called “checkout”. We can do both in one step by checking out a branch that does not exist, with the option -b (You can as always read about checkout, by writing “git help checkout”)

git checkout -b My_Spiffy_Feature

When we then write git status, we can see that we are on the new branch:

I then add the new files. with the new function in, and we want test that they work by calling the function in main:

We then compile our program (which gets default name a.out) and run it:

It works! Great, time to commit. We add the new files, BUT NOT main.c or a.out . They were just for testing, and is otherwise not related to our feature.

And we then push to the remote repository:

As you can see, git complained, because while we have created our branch, we had not really configured it yet (Specifically, we never told git what branch this new branch should originate from from. We just created it out in the void). But GIT TELLS you what to do. So I simply wrote the recommended command, and bam, branch is working as we want it to

I update the new feature file, just so we have more than one commit. I add the changes, commit and push again:

Now that our feature is done, we want to merge the branch into the master branch.

To showcase something, I will first have the other person make a change to main, add, commit and push it:

The first person will now merge their spiffy new feature in. They do that by switching to the master branch with git checkout:

We see that we are behind 1 commit, so we pull.

But horror! Since we have the unstaged changes, we cannot pull, since we changed main.c to tests our new feature, AND the other person have changed main, those two cannot exist at the same time. So what do we do? Well, in this case, we are ok with our tiny test in main.c being lost. So we remove it like so:

Notice how EVERYTHING I did here, was just read what GIT said was the problem, then write git status, and do the actions that GIT tells me I can do, which solves the problem. Ok, now we have the latest update of the master branch. Time to merge our feature in:

This time I did not use the -m feature (Because I forgot) so I just used the external program to write the commit message.

And if we write git log, we can see every single one of the commits. Both in the branch, and in the master:

And if we want to get a bit of a graphical representation of what happened, we can use git log --graph:

Now, this is the simple way to do branching. You actually have full control over how exactly you want to merge your branch in. In this case, the two commits of the branch was added AFTER the commit on master. But we COULD have merged the branch in so that the two commits on the spiffy function was done BEFORE the changes on master. When you are still starting out, do not worry about this. But that is the workflow. You create a branch, you work on your feature in it, where you cannot get in the way of anyone else. When your feature is done, you merge it into the master. This way, the master was always ready to show to your teacher/boss, and did not have half implemented things that you would have to explain should be ignored at any point.

Half of the benefit of the feature branch workflow is that it minimizes the chance for merge conflicts. For them to happen, 1 group would have to go to the master branch and pull. AFTER they pulled, but before they managed to merge their branch in, another group must pull from master, and merged their feature in.

Unlikely.

But let us talk about merge conflicts.

Are those not horrible things that break everything?

No. Merge conflicts simply means GIT could not figure out how to merge something, and so a human will have to do it for it. GIT is nice, and shows you exactly where the problem is, and how to solve it. Let us create a merge conflict. The first person adds in the function that uses their new spiffy feature after the hello world prinf, stages the changes and commits them. But do not yet push

The other person creates 2 more printf statements in main, stages the changes for commit, and commits them:

Now we have 2 commits, that both changes main.c How should these two be merged? Should the spiffy feature be called before or after the newly added prinf lines? GIT cannot know this, and so will tell the humans to do it. And the job falls to whoever wanted to push in a change that creates the merge conflict. In our example, I will have the second person, who added the extra printf lines push first:

And now the first person with their spiffy feature pushes, and:

It fails... But we are fine. Nothing actually happened here. The remote is still fine, and we locally are still fine. But we have to figure out how to fix this. When in doubt, use git fetch to get all the info but change nothing, and then git status:

(By the way, I made an honest mistake here, and did not push the branch changes after I merged. But I am not really in trouble, because GIT saved me! :D) And as we can see, GIT is once again telling us what to do. Great!

And we are now at the place where we need to decide what to do. While you are still new, I recommend the default strategy. So we do as GIT tells us to:

And now, FINALLY, we have our merge error. But notice that we only got it this way, because we asked for it. So… what does that mean? Git status to the rescue once more!

As expected, the problem is in main.c Let us check out what is in that file:

We have our changes first, then a separation, and then the other changes. And fixing it is piss easy. We remove the lines GIT inserted to tell us where the conflict was, and put the code in order. WE decide if the spiffy feature should be put before, after or in the middle of the two printf statements. I decide to put them in the middle like so:

Merging the two versions together, is in of itself, a change to the code. So we will now do what we always do when we have made changes. Add the files that we changed, and make a commit, and then push:

We have now resolved the merge conflict.

Notice how the problems that we ran into were not GIT problems. We ran into issues that ALWAYS come up when multiple people are working on the same project. But GIT made it really clear what the issues were, and forced us to deal with them in a smart way! :D